架构设计：复用是邪恶的
文章来源：分布式实验室
傅一平评语：
业务中台、数据中台都在强调复用，但我们不能只讲复用的好处，也要讲带来的坏处，关键是要找到那个临界点，这才是辩证统一的。这篇文章给出了两个原则：自治性和一致性，也提供了两条颇有深意的经验：
1、在业务层次是否要从多个业务模块中抽象出一个底层模块，可以通过多个业务模块的这部分公共逻辑部分是否要一起进行改变进行判断，如果不是需要一起变化的就不要抽象出公共模块。
2、根据个人经验如果你在要从各个业务模块进行抽象出一个模块保持一致与各模块保持自治之间犹豫时，要毫不犹豫优先选择「自治」，这个颇有点奥卡姆剃刀的样子，“如无必要，勿增实体”。
读来很有启发，推荐给你。
正文开始
在系统设计和写代码的过程中，我经常会听到「复用」这个词，以「复用」为目的来设计技术，业务，组织架构。例如：
抽象出一个类，函数，UI 组件，用于不同的场景
抽象出一个微服务，越细越好，这样可以灵活的组合
抽象出一个业务中台，沉淀各种基础业务功能，供全公司使用
组织（管理）架构中，抽象出一个职能竖井（后端，前端，QA，财务），被不同的产品使用
产品设计中要完成一个性能功能，发现跟之前一个功能相似，就复用之前的功能设计，改改继续用
为什么我们喜欢复用呢？
主要目的：既然一部分功能已经存在，为什么还要自己造呢？直接拿来用，这样我可以做得更少，所以能够提升个人的生产效率。
接受的教育：一直以来的教育，大部分工程师都学习过 DRY principle；《设计模式》的的英文书名就是 《可复用面向对象软件的基础》，都在强调复用。
编程习惯：在面向对象语言里，工程师习惯了继承，而继承对于大部分人来说的目的就是复用
认为复用可以提高效率的推理逻辑是怎样的？
如果我们要写一个系统的所有代码，我们需要写大量的代码。
如果我们能从其他地方重用一些以前写过的代码，我们就能写更少的代码。
我们能重用的代码越多，我们写的代码就越少。
我们写的代码越少，我们就会越早完成系统!
这样的推理逻辑是存在如下误区：
所有的代码（功能）需要相同的时间来写
写代码是完成系统的最主要工作
如果你要写得代码依赖很多其他的「复用」模块，你就要去理解不同的「复用」模块提供的接口，很多时候只看文档都不行；如果「复用模块」的接口不是正好是适用你的场景，你就必须在讲究使用接口和对方排期之间进行选择。
此外对于如何抽象出一个公共业务模块，大部分人都没什么标准，公共业务模块的负责人成了业务的外包，效率更低。
另一点是任何维护生产环境系统的人都知道写代码只是整个工作中一小步，而且是确定性最高的一步，之后维护才是最占用时间的。我们需要不断地进行调试，部署，再调试，部署。一个用于很多依赖的模块相对依赖少的模块做这些工作的难度是高很多的。
你说复用带来了这么多问题，那我们平时使用各种框架，基础算法库都要自己写一份吗？
肯定不需要自己再写一份，我们平时会使用各种编程语言（Java，Go），框架，库。我们使用这些没有任何问题，因为这是共识和标准，他们是足够「通用，一般化」，并不是为了某个业务或者某个公司定制的。先有「共识，标准」，再谈复用，绝对不是随意的拿过来用。
那我设计系统时，尽量将我的设计通用化就好了（例如拆很多个 CRUD 的微服务），这样就能更多的进行复用，提高生产效率对吗？
复用不是系统要追求的目标。很多人认为更多模块的「复用」，就可以做到像乐高一样快速搭建系统，但是很多复用并不是乐高，而是器官移植，不仅不能提高效率，要不断面对各种各样的排异反应，降低了速度和稳定性。很多创业公司快速发展时系统腐化的主要问题就出现在了强行复用上。强行复用的案例很常见，例如：
上百个字段的数据表（例如订单表，数据表），不清楚哪个字段在哪个场景下有效
根据名词来设计系统，出现业务中台，例如订单中台，电商中台，各部门之间不断地扯皮
出来无数个小的微服务，然后搞个统一的业务编排调度层（所谓的 gateaway）来处理业务，可能还抽象 DSL；上线十分复杂，需要发布 N 各模块；调度模块是系统大单点，稳定性迭代速度都是问题
如果有一个好的设计，我们需要谨记《Hints for Computer System Design》中的「Use a good idea again instead of generalizing it. A specialized implementation of the idea may be much more effective than a general one.」
那系统设计好的标准是什么？衡量的维度有优先级吗？
两个评价标准自治性和一致性：
自治性：受其他模块的影响程度，观测模块的接口是否稳定。可以使用AutonomyMetrics[1] 进行衡量
一致性：应该使用一个模块的地方使用一个模块的程度，也可以衡量是否过早，过度抽象了。可以使用 ConsistencyMetrics[2]
在业务层次是否要从多个业务模块中抽象出一个底层模块，可以通过多个业务模块的这部分公共逻辑部分是否要一起进行改变进行判断，如果不是需要一起变化的就不要抽象出公共模块。
根据个人经验如果你在要从各个业务模块进行抽象出一个模块保持一致与保持在模块保持自治之间犹豫时，要毫不犹豫优先选择「自治」。
总结
大部分情况下系统的核心复杂度不会减少， 只是转移；不会因为所有代码一个人写，会比分成两个人写更快，分工是应该且必须的。但是请注意的是：
不要为了复用随意通用化，抽象化，复用不是目的。如果要通用化就拿ConsistencyMetrics[2] 来判断是否是抽象合理的。
不要随意复用其他的模块，自治优先，用 AutonomyMetrics[1] 衡量；如果要复用一定要确保共识和标准优先，形不成共识和标准就不用复用。
相关链接：
https://autonomy.design/Part1/AutonomyMetrics.html
https://autonomy.design/Part1/ConsistencyMetrics.html
参考链接：
https://zhuanlan.zhihu.com/p/356202989
https://udidahan.com/2009/06/07/the-fallacy-of-reuse/
https://zhuanlan.zhihu.com/p/138145081
https://zhuanlan.zhihu.com/p/410049005
免责声明：本公众号所载文章为本公众号原创或根据网络搜索下载编辑整理，文章版权归原作者所有，仅供读者学习、参考，禁止用于商业用途。因转载众多，无法找到真正来源，如标错来源，或对于文中所使用的图片、文字、链接中所包含的软件/资料等，如有侵权，请跟我们联系删除，谢谢！
点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！